Return the sealed dal.DB from NewDatabase - #162
Merged
Conversation
dalgo v0.64.2 renames today's dal.DB to dal.Backend and seals dal.DB so
only dal.NewDB can produce one, gaining the framework's BeforeSave
validation and hook pipeline on every read-write transaction. Bump the
dependency and change NewDatabase's single return statement to
dal.NewDB(&database{...}), and update the package's var _ dal.DB
assertion to dal.Backend (a duplicate of that assertion is dropped in
the same edit).
dalgo2sql validates nothing itself today, so the framework's pipeline
is a pure addition rather than a change in behaviour, and every
existing check keeps passing unmodified.
Sealing dal.DB does ripple through the test suite, though: many
whitebox tests type-assert NewDatabase's return value straight to the
concrete *database so they can call adapter methods (Insert, Update,
Delete, onlyReadWriteTx, ...) that are not part of dal.DB. That
assertion now fails because the returned value is dal.NewDB's wrapper
struct, not *database. Recover the concrete backend at each of those
call sites with dal.BackendOf, exactly the escape hatch the framework
added for this. One of these, TestTransaction/Upsert, needed the same
fix a step earlier: it asserts a capability (Upsert) that is specific
to this adapter and not part of any dal package interface, so the
framework's validated transaction wrapper does not promote it either;
unwrapping via dal.BackendOf before opening the transaction restores
the adapter's own transaction type the assertion expects.
Add TestConformance, wiring the new dalgotest.RunConformance suite
against a real in-memory SQLite database via the same
modernc.org/sqlite driver already used elsewhere in this package's
tests, so it needs no external database or env-gate and genuinely
proves the framework validates writes before this adapter is entered.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SkkrXdtf8mU2GRo2hHsHT1
Signed-off-by: Alexander Trakhimenok <alex@trakhimenok.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
github.com/dal-go/dalgoto v0.64.2, which renames today'sdal.DBtodal.Backendand sealsdal.DBso onlydal.NewDBcan produce one — every read-write transaction it starts now runs the framework'sBeforeSavevalidation and hooks before this adapter's code is entered.NewDatabase's single return statement changes from&database{...}todal.NewDB(&database{...}); the package'svar _ dal.DB = (*database)(nil)assertion becomesvar _ dal.Backend = (*database)(nil)(a duplicate of that same assertion is dropped in the same edit).Validatereferences anywhere in the repo, tests included), so this is a pure addition, not a behaviour change.NewDatabase's return value straight to the concrete*database(to reach adapter methods likeInsert,Update,onlyReadWriteTx, ... that are not part ofdal.DB). Recovers the concrete backend at each withdal.BackendOf— the escape hatch the framework added for exactly this.TestTransaction/Upsert, which asserted an adapter-specific capability (Upsert, not part of anydalpackage interface) on the transaction handed into aRunReadwriteTransactionworker. The framework's validated transaction wrapper doesn't promote adapter-specific extras, so this needed the samedal.BackendOfunwrap one level up, before opening the transaction.TestConformance, wiring the newdalgotest.RunConformancesuite against a real in-memory SQLite database (the samemodernc.org/sqlitedriver already used bysql_map_get_test.go) — no external database or env-gate needed. All 16 checks pass.This is the adapter
dalgo2mysql,dalgo2postgres, anddalgo2sqliteall wrap, so landing it first gives all three the validation pipeline for free.Test plan
gofmt -l .— cleanGOWORK=off go vet ./...— cleanGOWORK=off go test -race -count=1 ./...— pass (includesTestConformance, genuinely executed, not skipped)end2end/submodule (separate go.mod, bumped the same way):GOWORK=off go test -race -count=1 ./...— pass, using the CGomattn/go-sqlite3driver against a real file-backed SQLite DB, all CRUD subtests ran (none skipped)🤖 Generated with Claude Code
https://claude.ai/code/session_01SkkrXdtf8mU2GRo2hHsHT1